home *** CD-ROM | disk | FTP | other *** search
/ ftp.cs.arizona.edu / ftp.cs.arizona.edu.tar / ftp.cs.arizona.edu / icon / newsgrp / group93a.txt / 000032_icon-group-sender _Tue Jan 19 01:36:47 1993.msg < prev    next >
Internet Message Format  |  1993-04-21  |  1KB
  1. Received: by cheltenham.cs.arizona.edu; Tue, 19 Jan 1993 05:48:11 MST
  2. Date: Tue, 19 Jan 1993 01:36:47 MST
  3. From: "Clint Jeffery" <cjeffery>
  4. Message-Id: <199301190836.AA02412@chuckwalla.cs.arizona.edu>
  5. To: icon-group@cs.arizona.edu
  6. In-Reply-To: (Richard L. Goerwitz's message of 18 Jan 93 16:35:57 GMT <1993Jan18.163557.6566@midway.uchicago.edu>
  7. Subject: detab/entab - anyone use them?
  8. Status: R
  9. Errors-To: icon-group-errors@cs.arizona.edu
  10.  
  11.    >I like having entab/detab as functions in the language.
  12.    Yes, but couldn't they just as well be library functions, and not
  13.    part of the core language implementation?
  14.  
  15. The conversation about a minimal, extensible Icon is getting interesting.
  16. A smaller Icon would have several compelling benefits for both users and
  17. language implementors, but I don't think we can "rob Peter to pay Paul"--
  18. so my question is: When is something in the language, but not in the language?
  19.  
  20. I think if Icon's linker knew about a standard archive of IPL procedures,
  21. and pulled out those procedures whose names appear as (undeclared)
  22. identifiers in the source program, we could make a library implementation
  23. of entab/detab so easy to use that most folks would consider them built-in.
  24.  
  25. And I know a hundred people are going to jump on me for saying it, but
  26. personally I think performance is not a very good rationale for entab/detab
  27. to be built-ins -- convenience and backward compatibility are better arguments.
  28.